Skip to content

Conversation

@ebyhr
Copy link
Member

@ebyhr ebyhr commented Sep 26, 2025

Description

Assemble the release notes for the upcoming Trino 478 release.

Additional context and related issues

See https://github.com/trinodb/trino/pulls?q=is%3Apr+is%3Aclosed+milestone%3A478

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.

Verification for each pull request

Format: PR/issue number, ✅ / ❌ rn ✅ / ❌ docs
✅ rn - release note added and verified, or assessed to be not necessary, set to ❌ rn before completion
✅ docs - need for docs assessed and merged, or assessed to be not necessary, set to ❌ docs before completion

25 Sep 2025

26 Sep 2025

28 Sep 2025

29 Sep 2025

30 Sep 2025

01 Oct 2025

02 Oct 2025

03 Oct 2025

04 Oct 2025

05 Oct 2025

06 Oct 2025

07 Oct 2025

08 Oct 2025

09 Oct 2025

10 Oct 2025

12 Oct 2025

13 Oct 2025

14 Oct 2025

15 Oct 2025

16 Oct 2025

17 Oct 2025

18 Oct 2025

20 Oct 2025

21 Oct 2025

22 Oct 2025

23 Oct 2025

24 Oct 2025

Summary by Sourcery

Add the Sphinx release notes page for Trino version 478 and register it in the documentation toctree.

Documentation:

  • Create docs/src/main/sphinx/release/release-478.md with detailed Trino 478 release notes covering general, security, Web UI, Docker image, and connector changes
  • Update docs/src/main/sphinx/release.md to include the new release-478 entry in the toctree

@wendigo
Copy link
Contributor

wendigo commented Sep 27, 2025

@ebyhr I've added two more entries

@ebyhr ebyhr force-pushed the ebi/release-note-478 branch 3 times, most recently from e51817f to 76113ca Compare October 2, 2025 01:37
@ebyhr ebyhr force-pushed the ebi/release-note-478 branch 3 times, most recently from 72cb5a4 to f11e381 Compare October 4, 2025 01:18
@ebyhr ebyhr requested a review from Copilot October 4, 2025 23:55
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds the release notes for Trino version 478, documenting new features, bug fixes, and improvements across various components and connectors.

  • Creates a comprehensive release notes document for version 478 with changes across general functionality, web UI, Docker, and multiple connectors
  • Adds the new release notes file to the documentation index to make it accessible

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
docs/src/main/sphinx/release/release-478.md New release notes document containing features and fixes for Trino 478
docs/src/main/sphinx/release.md Updated table of contents to include the new release-478 entry

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@@ -0,0 +1,106 @@
# Release 478 (dd Oct 2025)
Copy link

Copilot AI Oct 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release date placeholder 'dd Oct 2025' should be replaced with the actual release date.

Suggested change
# Release 478 (dd Oct 2025)
# Release 478 (3 Jun 2024)

Copilot uses AI. Check for mistakes.
@ebyhr ebyhr force-pushed the ebi/release-note-478 branch 3 times, most recently from 60a2313 to 57aaf2c Compare October 10, 2025 00:15
@ebyhr ebyhr force-pushed the ebi/release-note-478 branch 4 times, most recently from b011102 to 7299817 Compare October 16, 2025 06:32

## Docker image

* Run Trino on JDK 25.0.0 (build 36). ({issue}`26693`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: This will change to 25.0.1 soon

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we treating this as user visible? Because we support attaching external plugins to Trino run from official docker image?

@ebyhr ebyhr force-pushed the ebi/release-note-478 branch from fc92c59 to 56b8440 Compare October 21, 2025 22:46
Copy link
Member

@mosabua mosabua left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of changes and final clean up needed

@ebyhr ebyhr force-pushed the ebi/release-note-478 branch from f2013f8 to 04c1acc Compare October 22, 2025 23:47
@ebyhr ebyhr force-pushed the ebi/release-note-478 branch from b06fbfb to 412d267 Compare October 23, 2025 02:22
@ebyhr ebyhr marked this pull request as ready for review October 23, 2025 06:06
@sourcery-ai
Copy link

sourcery-ai bot commented Oct 23, 2025

Reviewer's Guide

This PR integrates the Trino 478 release notes into the documentation by updating the Sphinx toctree and adding a new release page with categorized change entries.

Flow diagram for Trino 478 release note integration

flowchart TD
    A["Update Sphinx toctree in release.md"] --> B["Add release/release-478 to toctree"]
    B --> C["Create release/release-478.md with categorized release notes"]
    C --> D["Documentation includes Trino 478 release notes"]
Loading

File-Level Changes

Change Details Files
Include new release in documentation index
  • Added "release/release-478" entry to the Sphinx toctree
docs/src/main/sphinx/release.md
Add detailed release note page for version 478
  • Created release-478.md with sections for General, Security, Web UI, Docker image, connectors, and SPI
  • Populated each section with bullet entries referencing relevant issue numbers
docs/src/main/sphinx/release/release-478.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there - I've reviewed your changes and they look great!

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location> `docs/src/main/sphinx/release/release-478.md:16-17` </location>
<code_context>
+* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically.
+  way. ({issue}`26938`)
</code_context>

<issue_to_address>
**issue (typo):** Remove the extraneous 'way.' fragment at the end of the sentence.

'way.' is likely a typo and should be deleted to improve clarity.

```suggestion
* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`)
```
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
@findepi findepi requested review from Copilot and mosabua October 23, 2025 09:16
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.


Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@findepi findepi changed the base branch from master to findepi/docs-checks October 23, 2025 17:06
@findepi
Copy link
Member

findepi commented Oct 23, 2025

FYI, i changed the target branch of this PR

@colebow
Copy link
Member

colebow commented Oct 23, 2025

Very funny (and unhelpful) that Copilot is randomly suggesting different PR numbers.

@findepi
Copy link
Member

findepi commented Oct 23, 2025

@colebow thanks for noticing!

BTW Whenever you see a bot's comment, like these copilot's, that you verified to be unhelpful, please resolve them (ideally along with thumb down reaction, but at least resolve)

Comment on lines +6 to +7
* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
* Add `retry-policy.allowed` configuration property to specify which query retry
policies can be selected by the user. ({issue}`26628`)

* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
* Add support for loading plugins from multiple directories. ({issue}`26855`)
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
Copy link
Member

@findepi findepi Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
* Add the `/v1/integrations/gateway` endpoint that exposes additional cluster metrics for Trino Gateway. ({issue}`26548`)

policies can be selected by the user. ({issue}`26628`)
* Add support for loading plugins from multiple directories. ({issue}`26855`)
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
* Allow dropping an uninitialized catalog that failed to load. ({issue}`26918`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to quantify this with "When using dynamic catalogs" or similar?

* When using dynamic catalogs, allow dropping ...

* Add support for loading plugins from multiple directories. ({issue}`26855`)
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
* Allow dropping an uninitialized catalog that failed to load. ({issue}`26918`)
* Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`)
* Improve performance of queries with an `ORDER BY` clause using `varchar` or `varbinary` types. ({issue}`26725`)

* Improve performance of queries with joins which spill to disk. ({issue}`26076`)
* Fix potential incorrect results when reading `row` type. ({issue}`26806`)
* Return all catalogs, including uninitialized ones, for queries from `metadata.catalogs`. ({issue}`26918`)
* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

this is a bug fix, so it's best to start with "Fix"

Suggested change
* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`)
* Fix `EXPLAIN ANALYZE` planning so that it executes with the same plan as would be used to execute the query being analyzed. ({issue}`26938`)

* Propagate `queryId` to [Open Policy Agent](/security/opa-access-control)
authorizer. ({issue}`26851`)

## Web UI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs say "The Preview Web UI is not suitable for production usage, and only available for testing and evaluation purposes."
Thus, any changes in that component are irrelevant from end user / trino operator standpoint. Release notes are for end users' and operators' consumption.

Let's remove all entries pertaining the preview web ui


## Delta Lake connector

* Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`)
* Fix failure when reading `map` type with `json` value type when a value is `NULL`. ({issue}`26700`)

* Add support for reading encrypted Parquet files. ({issue}`24517`, {issue}`9383`)
* Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`)
* Improve performance of queries using complex predicates on `$path` column. ({issue}`27000`)
* Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bug fix

Suggested change
* Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`)
* Fix writing invalid dates and timestamps before `1582-10-15` when writing ORC files by setting calendar type in the file footer. Previously, Trino did not set the calendar type in the file footer, and values before `1582-10-15` could be read incorrectly by other query engines such as Apache Hive. ({issue}`26507`)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcinsbd @raunaqmorarka does this apply to Iceberg connector too?


* Improve performance when writing sorted tables and `iceberg.sorted-writing.local-staging-path`
is set. ({issue}`24376`)
* Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not "procedure". The code calls this "table procedure"
But the docs calls it "command" https://trino.io/docs/current/connector/iceberg.html#remove-orphan-files

Suggested change
* Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`)
* Return execution metrics while running the `remove_orphan_files` command. ({issue}`26661`)


## SPI

* Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Connector is the name of the interface connectors implement.
The interface does not implement shutdown. Quite contrary, it lost its default implementation.

Suggested change
* Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`)
* Remove default implementation from `Connector.shutdown()`. ({issue}`26718`)

* Add `retry-policy.allowed` configuration property to specify which retry
policies can be selected by the user. ({issue}`26628`)
* Add support for loading plugins from multiple directories. ({issue}`26855`)
* Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I am not convinced we should have added that.
Trino and Trino Gateway are both projects we manage, so we can have coupling between them. That does not mean we should or want such coupling. Everything is a trade off, of course. If this endpoint exposes information previously unavailable, and also interesting to Trino Gateway only, we perhaps want to have it. But it doesn't look like this is the case here. The endpoint exposes cluster utilization metrics (memory, load), which are generally useful for observability and also for any other query routing logic. We should expose them in gateway-agnostic manner, rather than build a public-but-do-not-use-kind-of-internal-yet-public API.

cc @andythsu @wendigo @martint

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've discussed that already and settled on the decision that it's ok to have a client specific endpoint (like we have for the UI). We can revisit this decision but if it blocks the release we should just revert the change and move on

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok to have a client specific endpoint (like we have for the UI)

UI is not the best example, because it's maintained within this repo. The UI endpoints can change as the UI needs evolve.

This new endpoint is different. It's meant for the Trino Gateway, so in theory it should not be used by any other software. Any other query routing software will needs its own endpoint, which is quite undesirable. All this while the information exposed is no way trino gateway specific and could be exposed in a more reusable manner.

We can revisit this decision but if it blocks the release we should just revert the change and move on

Agreed!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you that it's undesirable to have an endpoint for each service and it should be in a reusable manner

IMO, the coupling between Trino Gateway and Trino is inevitable. If Trino changes, Trino Gateway will need to change. For example, in this PR because Trino 477 removed some of the jmx stats, which caused Trino Gateway to fail, we had to pin Trino version to 476 and look for workarounds.

For this endpoint specifically, yes the data it returns can be useful for other software as well and should be gateway-agnostic. But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes. Other software owners are welcome, of course, to use this endpoint, but it is their responsibility to make sure their software doesn't break at all times, even after we roll out new changes to this endpoint. It's another way of saying there's no SLA on this endpoint if they use it, whereas if we create a generic endpoint, there's implied SLA

At the end of the day, if other query routing logic software needs similar data to be returned, they will likely end up with similar code in their endpoint. Yes this results in duplicate code. But we can look into how to extract common logic to a helper function. At that point, maybe we will find some discrepancies in these seemingly-similar looking endpoints.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes.

I appreciate the openness but I doubt that would be want we would actually want to maintain in the project.

BTW trino already exports tons of metrics in standard format (that's why jmx became obsolete), so i don't quite yet understand why we need dedicated endpoints just for selected metrics useful for selected use case

@findepi findepi force-pushed the findepi/docs-checks branch from 212e26e to a0d9b10 Compare October 24, 2025 07:50
@findepi findepi deleted the branch trinodb:findepi/docs-checks October 24, 2025 11:15
@findepi findepi closed this Oct 24, 2025
@findepi
Copy link
Member

findepi commented Oct 24, 2025

  • it will auto-udpate back to master when that PR is merged

it's how i saw it working many times, but this time it did not work.
sorry

@findepi
Copy link
Member

findepi commented Oct 24, 2025

unfortunately it is not possible to reopen this PR, even after i recreated the base branch
i copied current state of this PR to a new one

i will go over recent comments and apply them as separate fixup there.

@ebyhr ebyhr deleted the ebi/release-note-478 branch October 24, 2025 23:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.